The present invention relates to Service-Oriented Architecture (SOA) of a computer network system, particularly to a method for enforcing context model based SOA policies and a policy engine.
Service-Oriented Architecture (SOA) is a software system architecture which is realized by connecting independent functional entities capable of completing specific tasks to meet requirements of business integration in an Internet environment. The SOA is a component model which links different function units (called services) of an application through interfaces and contracts properly defined among these services, wherein the definition of the interfaces is independent of the hardware platform, operating system and programming language for realizing services. The SOA uses the service-oriented modeling technique and WEB service technique to accomplish loose coupling between systems and thus realize integration and cooperation between the systems.
The SOA policy is an important component of the SOA system and is used for declarative description and execution of the SOA system behavior. In the SOA system, the usage of the SOA policy spans different phases across the SOA lifecycle, including design time validation, deployment time policy publication and package and runtime service selection, change management and impact analysis.
Generally, the SOA policy may be classified into the following types in different layers:                Business policy for business decision making and industry guideline compliance, etc.        Application policy for service selection during service invocation, etc.        Governance policy for enforcing rules for standards compliance, and defining system behaviors for a governance process, etc.        
A main feature of SOA is that all the data and contexts are described in XML language, and a document containing such data and the contexts is called an SOA metadata document. Generally, the SOA metadata document may include: a service metadata document for describing contents relating to a service, a runtime information document for describing contents relating to the runtime information, and a document for describing other business contents. For example, the service metadata document may use Web Service Description Language (WSDL), XML Schema Definition (XSD), Web Service Policy (WS-Policy), Service Component Definition Language (SCDL), Business Process Execution Language (BPEL), Service Component Architecture (SCA) policy, etc. The runtime information document may use Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc. The document for describing other business contents may use Service Data Object (SDO), Web Ontology Language (OWL), etc.
Next some policy engines in the prior art will be briefly described.
I. Business Policy Engine
In the prior art, there are many business policy engines, such as ILOG JRule Engine, Drools, Mandarax, JLisa, JEOPS, OpenRules, etc.
The ILOG JRule Engine is a flexible, high performance execution platform suitable for standalone use with a J2SE or J2EE application. This Engine supports strong policy/rules language customization, for example, Business Action Language (BAL, which uses natural language syntax to define the policies/rules), ILOG Rule Language (IRL, which uses Java- or XML-like syntax to define the policies/rules), Business Rule Language Definition Framework, Java Language Integration which uses Java expression directly in IRL, etc.
Drools is an open source object-oriented policy/rule engine for Java. Drools provides for declarative logic programming and is flexible enough to match the semantics of the user's problem domain. Drools is an implementation of JSR94 specification. The related detailed description may be found in http://java-source.net/open-source/rule-engines/drools.
Mandarax is an open source Java class library for deducting policies/rules. It provides an infrastructure for defining, managing and querying policy/rule bases. The related detailed description may be found in http://java-source.net/open-source/rule-engines/mandarax.
JLisa is an open source framework for building business policies/rules accessible to Java and it is compatible with JSR94 specification. The related detailed description may be found in http://java-source.net/open-source/rule-engine s/jlisa.
The Java Embedded Object Production System (JEOPS) is an open source Java based Forwarding Chaining policy/rule engine. This engine is used to power up the business process by the policies/rules in Java Application Servers, client applications, and Servlets. The related detailed description may be found in http://java-source.net/open-source/rule-engines/jeops-the-java-embedded-object-production-system.
OpenRules is a full-scale open source business policy/rule management framework. It efficiently uses MS Excel, Eclipse Integrated Development Environment (IDE) and open source Java libraries to create, deploy, execute and maintain different policy/rule engines with complex business logic. The related detailed description may be found in http://java-source.net/open-source/rule-engines/openrules.
Some policy/rule engines may support Forwarding Chaining for reasoning a set of policies/rules applied to specific policy subjects. The so-called Forwarding Chaining is a forwarding chaining for the set of rules in a rule system. Particularly, if the execution of rule 1 changes a state of a target system on which the current set of rules operates and causes rule 2 to be matched and executed, the reasoning from rule 1→ rule 2 is called forwarding. Thus, if there exists a chaining of rule 1→ rule 2 . . . → rule n, the reasoning of the rule engine on the whole chain is called forwarding chaining. The forwarding chaining is a mechanism which allows the policies/rules applied to the same knowledge space to be inter-triggered, that is, the execution of one policy/rule is triggered by the execution of another policy/rule.
In the forwarding chaining mechanism, the policies/rules are parsed as a memory model, and variables referenced in the condition part and action part of the policy/rule are represented as memory variables. During the execution of forwarding chaining, the deduction is done by updating the memory variables and interchanging states across the different policies/rules. FIG. 1 is a schematic diagram showing an example of the existing forwarding chaining mechanism. As shown in FIG. 1, “WM” represents working memory which could be regarded as a storage unit of variables of the policies/rules. The variable may be changed by another rule's execution. In the forwarding chaining mechanism, the most time consuming step is matching the WM with the condition part of the policy/rule. This step is to discover the effective WMs which have been changed by a rule's execution and which will trigger another rule.
There are lots of forwarding chaining algorithms in the prior art and the most famous is RETE algorithm. The main features of this algorithm are: (1) state-saving, i.e. after each change to the WM, the state (result) of the matching process is saved in α and β memories (after next change of the WM, many of the results are usually unchanged, so the RETE algorithm avoids a lot of re-computation by keeping these results between successive WM changes); (2) sharing of nodes between productions with similar conditions, i.e. at the output of the network, when two or more productions have a common condition, the RETE algorithm uses a single α memory for the condition, rather than creating a duplicate memory for each production, and in the β part of the network, when two or more productions have the same conditions, the same node are used to match these conditions, thereby avoiding duplication of the matching.
However, the existing business policy/rule engines have the following limitations:
1. The existing business policy/rule engines focus on enforcement of business policy/rule, and take no care of other types of SOA policy.
2. The existing business policy/rule engines lack dedicated solutions for the SOA feature, i.e. using XML format. For example, RETE algorithm assumes that both the policies/rules and the context to be validated will be parsed as the memory model to interchange states across different policy/rule's execution. However, in XML, Document Object Model (DOM) consumes a lot of memories and it is difficult to locate specified elements in a large XML document. Thus, the policies/rules and the applied model in XML format are not adapted to be loaded as the memory model periodically. In addition, the traditional way to validate the XML content does not require a memory model, and thus RETE algorithm will lose its position.
3. The existing business policy/rule engines always define their own policy/rule formats. So the policies/rules defined for one engine are difficult to be widely adopted and reused.
4. The existing business policy/rule engines cannot deal with the feature of using the XML language in the SOA system. So a complex mechanism needs to transform information and be integrated in the SOA system. For example, ILOG policy/rule engine is encapsulated as policy/rule services for usage in a FileNet workflow system.
5. In the existing business policy/rule engines, policy/rule expressions have fixed terminologies, such as Java specific expression, reserved XML structure or terms (RuleML, SWRL, etc.). It will lead to rigid engine implementation or reasoning infrastructure. In addition, application domain and contexts to which the policies/rules are applied are also fixed.
II. Application Policy Engine
In the prior art, there are some application policy engines which may be used in the SOA system. Typically, these application policy engines are based on ontology, such as IBM WebSphere Business Service Fabric (WBSF), Semantic Web Rule Language (SWRL) engine, SweetRules engine, TRIPLE engine, SEW engine, etc.
WBSF is a dynamic assembler for selecting service endpoint leveraging ontology. It only uses terms in OWL file to define a condition part of the policy.
SWRL is based on a combination of OWL DL and OWL Lite sublanguages of the Web Ontology Language (OWL) with Unary/Binary Datalog RuleML sublanguages of Rule Markup Language (RuleML). It extends the set of OWL axioms to include Horn-like policies/rules. It thus enables Horn-like policies/rules to be combined with an OWL knowledge base.
The SweetRules engine is an open source integrated set of tools for semantic web rules and ontology. It revolves around the Rule Markup/Modeling Language (RuleML) emerging standard for semantic web rules and supports the related SWRL and the OWL standard for semantic web ontology. The related detailed description may be found in http://java-source.net/open-source/rule-engine s/sweetrules.
The TRIPLE engine is a semantic Web engine supporting RDF and a subset of OWL Lite. Its syntax is based on F-logic and supports an important fragment of first-order logic. The related detailed description may be found in http://triple.semanticweb.org.
The SEW engine is an implementation of a RDF schema engine. It includes some XML schema data type support and may read RDF graphs serialized in RDF/XML and N-TRIPLES formats.
However, such application policy engines only support one-step reasoning and are adapted to a specific industry, rather than other fine grained policy subjects, such as a project, an application or a service. Additionally, it also relates to many complex standards, which leads to the application policy engines being complex.
III. Service Modeling Language (SML) Based Engine
SML is defined by IBM, Microsoft, BEA, Intel etc. for XML based IT service management. It provides a rich set of constructs for describing models of complex IT services and systems. The SML model is a set of interrelated XML documents. The XML documents contain information about the parts of an IT service, as well as the constraints which each part must satisfy for the IT service to function properly.
The documents in a SML model include definition documents and instance documents.
A definition document is described with XML Schema Definition (XSD) language and Schematron Schema language and is a subset of documents in the SML model that describes the schemas and polices/rules that govern the structure and content of the documents in the model. The SML specification define two kinds of definition documents, i.e. XML schema documents which conform to SML's profile of XML schema and policy/rule documents which conform to SML's profile of Schematron. The policy/rule documents are Boolean expressions that constrain the structure and content of the documents in the model.
An instance document is in XML format and is a subset of documents in the SML model that describes the structure and content of the modeled entities.
However, the SML based engine is only for IT system management because the SML's original goal is for system management, model drive modularity, re-use and standardization, such as Microsoft System Management Server. In addition, the SML based engine is only for one-step validation of system configuration and report. SML utilizes Schematron as policy/rule expression to validate its instance documents. According to the Schematron specification, the policies/rules within the standard Schematron may only report a diagnosis message in text string format when there is a violation to policy/rule restrictions. The SML specification extends the capability of validation report to bring in structured output, but this extension only provides a standard output of elements or attributes, without further semantics.